home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940187.txt < prev    next >
Internet Message Format  |  1994-11-13  |  10KB
  1. Date: Mon, 29 Aug 94 04:30:09 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #187
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Mon, 29 Aug 94       Volume 94 : Issue  187
  11.  
  12. Today's Topics:
  13.                            ethernet timing
  14.                 KPC-2/KAM front end test connectivity
  15.  
  16. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  17. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  18. Problems you can't solve otherwise to brian@ucsd.edu.
  19.  
  20. Archives of past issues of the TCP-Group Digest are available
  21. (by FTP only) from UCSD.Edu in directory "mailarchives".
  22.  
  23. We trust that readers are intelligent enough to realize that all text
  24. herein consists of personal comments and does not represent the official
  25. policies or positions of any party.  Your mileage may vary.  So there.
  26. ----------------------------------------------------------------------
  27.  
  28. Date: Sun, 28 Aug 1994 17:56:49 +0200
  29. From: Geert Jan de Groot <GeertJan.deGroot@ripe.net>
  30. Subject: ethernet timing
  31. To: TCP-Group@ucsd.edu
  32.  
  33. On Sun, 28 Aug 94 04:30:02 PDT  Advanced Amateur Radio Networking Group wrote:
  34. > Does anyone remember an article in some unix magizne about ethernet timing
  35. > issues with new chip sets having shorter inter-gap delays or something
  36. > like that.
  37.  
  38. Here you are...
  39.  
  40. Geert Jan
  41.  
  42. ------- Start of forwarded message -------
  43. Newsgroups: comp.dcom.lans.ethernet
  44. Path: cronkite.cisco.com!decwrl!parc!wirish
  45. From: wirish@parc.xerox.com (Wes Irish)
  46. Subject: Performance problems on high utilization Ethernets
  47. Message-ID: <wirish.750731783@misty>
  48. Summary: High utilization Ethernet performance problems traced to controller im
  49. plementation bugs
  50. Keywords: Ethernet, communications, interframe gap, IFG, collisions, controller
  51. , interface, packet loss, data link
  52. Sender: news@parc.xerox.com
  53. Organization: Xerox PARC
  54. Date: 16 Oct 93 00:36:23 GMT
  55. Lines: 115
  56.  
  57. For the past year or so I have been investigating performance problems
  58. on the Ethernets here at PARC.  This work has uncovered problems with a
  59. number of Ethernet controllers in common use today.  These low-level
  60. controller problems can lead to serious performance problems for many of
  61. the systems involved.  A full paper on this work, "Investigations into
  62. observed performance problems on high utilization Ethernet networks",
  63. will be released soon (initially as a PARC Blue & White report).  But,
  64. since I have been giving talks on this work and news of it has begun to
  65. hit the Internet, I feel that a should post a preliminary report in
  66. order to reduce speculation and to make sure that the facts are
  67. correctly stated.  Below is a short summary of some of the key facts and
  68. issues.
  69.  
  70. The Ethernet specifications talk about making sure that transmitters
  71. enforce a 9.6 microsecond gap (IFG) between frames (packets).  This is
  72. straight forward in the case of a gap following a just completed good
  73. packet.  But, gaps following collision events are less straight forward.
  74. I do not want to debate the details of what is and is not "correct" in
  75. this case -- that is a discussion for another time and place.  The
  76. reality of the situation is that there are a number of controllers in
  77. wide-spread use on networks today that do not interoperate very well in
  78. the face of collisions.
  79.  
  80. In general, the problems arise when the gap following a collision is too
  81. short for a particular implementation of a receiver.  In addition to
  82. uncovering controllers that simply generate short IFGs I have also
  83. uncovered a major implementation bug in a particular chip that injects
  84. short signal bursts onto the network.  These bursts can damage the IFG
  85. "enforced" by other machines.  Either way, the result is that same -- a
  86. short IFG preceding a packet which can result in a missed packet.
  87.  
  88. It is important to note that when a controller misses a packet due to a
  89. short IFG THE FACT THAT THE PACKET WAS MISSED IS NOT DETECTED NOR
  90. REPORTED TO THE SYSTEM.  System and driver statistics will claim no
  91. packets lost (unless some are lost for other reasons).  Even most
  92. network analyzers are subject to the same undetected and therefore
  93. unreported packet loss.  I have resorted to using a digital oscilloscope
  94. to capture and analyze these events.
  95.  
  96. Let me emphasize that these problems are almost exclusively related to
  97. dealing with collision events.  On a lightly loaded network, where
  98. collisions are few and far between, these problems are virtually
  99. non-existent.  But these problems do indeed come into play on moderate
  100. to heavily loaded networks.  Based on my observations a VERY ROUGH
  101. network load dividing line is about 25% load (using 0.1 or 1.0 sec
  102. samples).
  103.  
  104. Here is an enumeration of some of the facts related to particular
  105. controllers that I have uncovered so far.  There may be problems with
  106. other controllers but they may not appear on the networks that I have
  107. inspected.
  108.  
  109. Controller: Intel 82586
  110. Commonly found in: SUN 3's and SUN 4's (ie interfaces), many other
  111. machines
  112. Problem: Can generate a short IFG following a collision
  113. Cause: starts IFG timer on CS dropout
  114.  
  115. Controller: Intel 82596
  116. Commonly found in: Network General Sniffer using Cogent interface card
  117. Problem: Will not hear packet unless preceding IFG is 4.6 usec or larger
  118.  
  119. Controller: SEEQ 8003
  120. Commonly found in: Cisco MEC and MCI interfaces, older SGI (Silicon
  121. Graphics) including 4D/35 and Indigo (but not Indigo2)
  122. Problem: Can generate a short IFG following a collision
  123. Cause: Starts 9.6 usec timer at end of its on jam and not end of
  124. collision
  125. Problem: Generates 24 bit signal burst onto network following some
  126. collisions.  This burst lands in the IFG following the collision and
  127. will often result in two short IFGs resulting in other controllers
  128. missing the packet.  NB: this can happen even if the chip has nothing to
  129. transmit!
  130.  
  131. Controller: AMD 7990 "LANCE"
  132. Commonly found in: SUN SPARCStation machines (SS-1, SS-1+, SS-2, SS-10,
  133. ...), many DEC machines, Cisco/SynOptics routers, Cisco IGS, many other
  134. machines
  135. Problem: Will not hear packet unless preceding IFG is 4.1 usec or larger
  136. Cause: implementation state machine
  137. Problem: many other problems including lock-up, transmit gaps greater
  138. than 9.6 usec under load, etc.
  139. Fix: A new version of the controller, the 79C90 CLANCE, fixes many of
  140. these problems but is not in common use like the LANCE.
  141.  
  142. Interface chip: AT&T T7213
  143. Commonly found in: SUN SPARCStation 10 and other newer SUN machines
  144. Problem: Will hold the collision (and kill data) sent to the controller
  145. chip across IFGs of roughly 1.0 usec or less.  It will also do this if a
  146. "manchester coding violation" is detected in a packet -- a job that
  147. should be left to the controller.
  148.  
  149.  
  150. The result of all of these implementation details is that it is very
  151. possible, even probable, to put together a network that results in
  152. "undetected" packet loss.  Packet loss rates of even less than 1% can
  153. result in performance hits as high as 80%, depending on a multitude of
  154. factors including the protocols and implementations being used.  I have
  155. clocked the potential packet drop rate at PARC due to these problems to
  156. be in the 1% - 5% range at times.
  157.  
  158. I have been working with many of these vendors for a number of months
  159. now in an attempt to get these various bugs fixed so that different
  160. equipment interoperates properly.  Most of the vendors have been very
  161. receptive to making things work now that they know there is a problem.
  162. Some have already identified solutions while others are still working on
  163. them.
  164.  
  165.  
  166. Wesley Irish
  167. Network Scientist
  168. Xerox PARC
  169. wirish@parc.xerox.com
  170.  
  171. [Please send any replies via e-mail as I do not normally read netnews]
  172.  
  173. ------------------------------
  174.  
  175. Date: Mon, 29 Aug 1994 11:13:07 +0700 (GMT+7:00)
  176. From: "Sahry RA." <sahry@hafni.aia.bppt.go.id>
  177. Subject: KPC-2/KAM front end test connectivity
  178. To: tcp-group@ucsd.edu
  179.  
  180. Dear Tcp-Group,
  181.  
  182. I have a problem to make front end test modem between KPC-2 and KAM
  183. using AX.25 (net091b.exe, KA9Q modification), see figure below :
  184.  
  185.  
  186.         PC                                       PC
  187.          +                                       +
  188.     -----|--------- TCP/IP AX.25 net091b---------|-----
  189.        Modem                                   Modem 
  190.        KPC-2                                   KAM
  191.          |                                       |
  192.          + --->AFSK OUT ----cable----> AUDIO---->+
  193.          |                             IN        |
  194.          +<--- AUDIO IN ---cable<---- AFSK OUT---+
  195.          |                                       |
  196.          +-----------------ground----------------+
  197.  
  198.   PROTOCOL SESSION
  199.   ----------------
  200.   Initial Connection from KPC-2 :
  201.  
  202.         SEND IP        --------------------------> RECV
  203.         RECV SEND ACK  <-------------------------  SEND ACK
  204.         SEND REPLY     ------------------------->  RECV REPLY
  205.                                                    NO SEND REPLY ACK
  206.  
  207.   Initial Connection from KAM :
  208.  
  209.         RECV          <-------------------------- SEND IP
  210.         SEND ACK      --------------------------> NO RESPOND
  211.                       <-------------------------  SEND IP AGAIN (TRY
  212.                                                   AGAIN)
  213.                                                   ...continue send IP..
  214.  
  215.  
  216. So, with experiment above. I would like to implement them on WAN
  217. via 4-wire sattelite connection seems look below :
  218.  
  219.          NODE                                       NODE
  220.           A  TX                                  RX  B
  221.              +-------------TX Line ----------------+
  222.              +-------------------------------------+
  223.         KPC-2                                      KAM
  224.              +-------------RX Line ----------------+
  225.              +-------------------------------------+
  226.              RX       Sattelite SCPC voice        TX
  227.  
  228.  
  229. My problem :
  230.  
  231. 1. Is it my simulation test correct ?
  232. 2. How about drop voltage from Input/Output Modems ?
  233. 3. Shall I put buffer among Input/Output Modems ?
  234.  
  235.  
  236.  
  237. Best regard,
  238.  
  239. sahry
  240.  
  241. ------------------------------
  242.  
  243. End of TCP-Group Digest V94 #187
  244. ******************************
  245.